隨著時代變遷，企業需要加快創新與攻占市場，透過加速應用程式建置週期來獲得競爭優勢，已成為不可或缺的條件之一，面對這樣的需求，大型應用程式充滿挑戰，如：要如何更快地建置應用、提高開發效率等。當今較佳的解決方案是 微服務(Microservices)。

為什麼大型應用程式受到影響？

過去軟體開發的主流架構為 單體式架構(Monolithic Architecture)，會將所有功能集中在同一份專案中，如：主要業務功能、身分驗證、檔案上傳等，這樣的架構在小型應用程式、開發初期或是早期的應用程式是非常常見的。

單體式架構被廣泛使用是因為它具有下列優勢：

• 部署方式單純：僅需針對單一專案進行部署即可。
• 初期開發成本低：在開發初期因為只需專注在單一專案且程式碼量不多，故開發成本是很低的。

但單體式架構也不是萬能的，隨著專案規模擴大，它的劣勢會逐漸浮現：

• 不易維護：隨著程式碼增長與複雜度提升，維護成本逐漸提高。
• 合作困難：隨著業務範圍增長，開始需要與其他團隊合作開發，因為都要動到相同的程式碼，導致合作上出現困難。
• 無法獨立部署：由於所有功能都在單一專案中實作，導致每次變動都需要重新建置與部署整個應用程式。
• 限制技術：所有團隊在開發時，都必須使用相同的技術。
• 不易擴展：無法針對特定功能進行擴展。
• 單點故障：一但發生異常，所有功能將一起發生異常。

綜觀上述的優缺點可以得知，大型應用程式使用單體式架構絕對是弊大於利，當維護成本提高、團隊合作效率低、建置與部署速度慢，將無法達到加快應用程式建置週期的需求，進而導致 失去競爭優勢。

為什麼微服務會是較佳的解決方案？

受惠於 Docker 等容器化技術，讓我們可以更輕易地將程式碼模組化，並且以 容器(Container) 為單位進行切分，把一個應用程式拆分成 多個獨立元件(Component)，每個元件就是一個 服務(Service)，有屬於自己的業務範圍，如：業務服務、身分驗證服務等，而這些元件會採用特定的方式進行溝通，像是：RESTful API、RPC。

微服務架構具有下列優勢，使它成為大型應用程式架構上較佳的解決方案：

• 較容易維護：由於服務會專注在自己的業務範圍，故該服務的專案複雜度較單體式架構簡單。
• 較容易合作：由於服務是獨立的，各團隊間的合作將專注在介面的規格與串接。
• 可獨立部署：可以只針對改動的服務進行重新建置與部署。
• 技術自由：各個團隊可以根據需求來決定服務所使用的語言、框架等。
• 易於擴展：可以針對特定服務進行擴展。
• 不會單點故障：當某項服務發生異常，不會導致其他服務發生異常。

不過微服務架構也不是萬能的，在設計上也存在許多挑戰：

• 依賴關係：由於服務間存在依賴關係，需要注意服務異動會不會影響其他服務的運作，以及服務間的依賴關係是否有問題。
• 服務的顆粒度：如何定義一個服務的範圍是一件極具挑戰性的事情，顆粒度過大、過小都有可能導致依賴關係出問題或是增加整體複雜度。
• 監控：由於會存在多個服務，每一個服務都有可能成為其他服務的斷點，所以需要有非常良好的監控機制，確保發生問題時可以迅速找出斷點。

綜觀上述的優缺點，透過提升維護性、團隊合作效率、建置速度，可以滿足加快應用程式建置週期的需求，讓企業保有一定的競爭優勢，所以比起單體式架構，大型應用程式更適合使用微服務架構。

NestJS 與微服務

NestJS 是一套基於 Node.js 的後端框架，詳細的入門文章可以參考我之前寫的NestJS 帶你飛！系列文。

圖片來源

在系列文中有提到，NestJS 除了基本的 RESTful API 之外，還可以實作微服務架構，看到這邊應該有些讀者心中會浮現一個疑問：微服務不是用 RESTful API 就可以讓服務之間進行溝通嗎？為什麼還要特別寫可以實作微服務架構呢？確實使用 RESTful API 就可以讓服務之間進行溝通，不過在微服務的世界裡，會依照實際情況決定採用何種溝通方式，RESTful API 只是其中一種，還有許多溝通的媒介，像是：gRPC、NATS 等。

面對各種不同的溝通方式，NestJS 盡可能讓開發者可以使用相同風格的開發方式，將框架的整合度提升一個層次，整體開發體驗十分良好，可說是整合度極高的框架。

關於本系列文

先前的系列文主要是撰寫 NestJS 的入門文章，內容是以 RESTful API 為主軸，在這微服務當道的年代，我認為有必要整理一系列的文章來介紹如何用 NestJS 闖蕩微服務，希望對於推廣 NestJS 有更多的幫助。不過微服務架構涉及的技能樹很廣，所以這次的系列文會包含一些微服務相關的技能與管理方式，進而降低閱讀此系列文的門檻，也讓初探微服務的朋友，可以藉由這個系列文更加認識微服務的生態圈。

本系列文預計規劃如下：

1. NestJS 微服務應用程式篇：約 10 ~ 12 篇，會針對 NestJS 微服務應用程式做介紹，並在過程中介紹一些常見的溝通媒介。
2. 微服務的健康與可觀測性篇：約 6 ~ 8 篇，會介紹可觀測性相關的技術並與 NestJS 應用結合。
3. 微服務的管理策略篇：約 2 ~ 4 篇，會介紹管理微服務程式碼的策略，並以 NestJS 為例。
4. 微服務的設計模式篇：約 6 ~ 8 篇，會介紹在微服務架構下該如何透過 Pattern 來解決問題，會以 NestJS 為例進行實作。

另外，在文章中會有一些規則需要先了解：

1. 終端機(terminal)：在本系列文中會使用到終端機，它在 Windows 裡面稱「命令提示字元」，在 Mac 裡面稱「終端機」，後面統一叫「終端機」。
2. 指令(command line)：本系列文會在終端機下指令，有時候指令會有命名的部分，這邊會用 <大寫英文> 當作佔位，讀者們自行輸入欲命名之名稱。另外，所有的指令開頭都會有一個 $ 表示這是指令，無須輸入該符號。
3. 獨立篇幅：我會盡可能讓每一篇都是可以獨立閱讀的，讓各位在回頭看此系列文時，可以針對想要了解的部分去閱讀，不被前後文影響，但如果是同一主題拆成好幾篇的話，就可能會有前後文關係，再麻煩各位見諒一下。

廢話不多說，準備用 NestJS 闖蕩微服務吧！

具備條件

建議讀者具備以下條件，會比較容易理解接下來我所分享的內容：

1. 熟悉 NestJS 的基本使用方式。
2. 熟悉 TypeScript。
3. 熟悉 Node.js。
4. 熟悉 Docker 與 Docker Compose。

開始之前...

提醒：Node.js 也可以使用 nvm 進行安裝。

1. 至 Node.js 官網下載並安裝 Node.js，這邊建議安裝 LTS 版本，會比較穩定。
2. 使用 VSCode 等自己喜歡的編輯器。
3. 至 Postman 官網下載並安裝 Postman。
4. 安裝 NestJS CLI，可以參考官方文件或我之前分享的文章。
5. 有任何問題都可以與我分享喔！